mod3fandomcom-20200214-history
Scrum (Software Capability Rational Unified Model)
Was ist Scrum? Scrum (Software Capability Rational Unified Model) ist ein Agiles Projektmanagementframework, es beschreibt somit Praktiken für das Management von (Software-)Projekten. Es ersetzt den deterministischen vorausplanenden Ansatz, welcher alle (auch zukünftige) Ereignisse durch Vorbedingungen eindeutig festlegt, durch eine empirisch adaptive Projektsteuerung. Scrum wurde von Ken Schwaber 1999 eingeführt und 2002 durch sein Buch "Agile Software Developement with Scrum" breiter bekannt. Scrum regelt nicht welche Softwareentwicklungstechniken die Entwickler einzusetzen haben, die Wahl der Softwareentwicklungstechniken wird der Selbstorganisation des Teams überlassen. Meist werden Praktiken angewandt die aus dem Extreme Programming stammen. Im Bezug auf das Testen der Software gibt Scrum ebenfalls nicht vor wie das Testen im ablaufenden Projekt gestaltet werden soll. Projektmanagementinstrumente Das Ziel von Scrum ist es schnell und unkompliziert auf Änderung zu reagieren und keine Zeit und Kosten zu verschwenden. Hierfür hat Scrum mehrere Projektmanagementinstrumente zur Verfügung. Kurze Iteration Scrum unterteilt ein Projekt in mehrere Iterationen, welche eine fest vorgeschriebene Länge haben.Bei jeder Iteration, bei Scrum heißen diese auch Sprints, ''soll es möglich sein ein potenziell auslieferbares Produkt zu erzeugen, dessen Umfang pro Iteration wächst. Der Grund dafür ist simpel, da die einzelnen Sprints nur einen kurzen Zeitraum einnehmen ist es so deutlich einfacher diese im voraus durch zu planen. '' Product Backlog Hierbei wird die Planung nur auf eine simple Liste reduziert, welche lediglich die Arbeitsergebnisse darstellen soll wodurch eine Menge Arbeit erspart bleibt. Dieses Product Backlog wird vom Product owner (s.u.) geführt und enthält alle Anforderungen und Arbeitsergebnisse. Die einzelnen Elemente des Product Backlog werden nun priorisiert wobei auch eine chronologische Reihenfolge oder ein Abhängigkeit nicht geachtet wird. Das Product Backlog ist nicht von Anfang an fest geschrieben sondern wird, wie es bei Agilen Prozessen sein sollte, weiter entwickelt und bearbeitet. Dieses Bearbeiten nennt man auch "Backlog Grooming". Durch dieses dauerhafte neu bearbeiten und priorisieren wird der Plan zuverlässiger, da alles was vermieden wird was Fehler einbringen könnte. Sprint Backlog Auch in Scrum muss sich das Team mit dem Product owner zusammen überlegen wer wann welche Anforderungen abhaken kann und Aufgaben erledigen muss. Dies wird pro Sprint immer entschieden und so Schritt für Schritt gemacht. Der Sprint Backlog ist die kleinere Version des Product Backlog. Das Team nimmt sich die am höchsten Priorisierten Anforderungen und Aufgaben und packt diese in den Sprint Backlog. Während dessen müssen sie darauf acht geben, dass alles passend formuliert ist und verstanden werden kann. Alle Anforderungen die nicht ausreichend formuliert sind erfüllen somit nicht die Definition of Ready(Auswahl Kriterium), welche bestimmt ob die Aufgaben in den anstehenden Sprint kommen. Alle, die die Definition of Ready erhalten haben, werden nun in den Sprint Backlog gepackt und jetzt wird auch entschieden ob Abhängigkeiten, resultierenden Aufgaben und Aufwände und eine zeitliche Reihenfolge vorhanden sind, um somit die nötigen Aufgaben für den Sprint aus zu sortieren. Sobald dies geschehen ist legt das Team Ausgangskriterien[http://mod3.wikia.com/wiki/Scrum_Definition_of_Done_%28DoD%29?venotify=created (Definition of Done)] fest. Es muss darauf geachtet werden, dass diese Überlegungen nur für den anstehenden sprint gemacht werden, damit der Aufwand gering gehalten wird. Der Sprint Backlog darf während der Sprint läuft nicht mehr verändert, weil wenn man den Sprint wie angegeben plant bestehen gute Chancen das der Plan eingehalten wird. Timeboxing In Scrum hat jeder Sprint die Pflicht lieferfähige Software("potentially shippable product") hervorzubringen. In das Sprint Backlog kommen nur Aufgaben die zu einem einsetzbaren Produkt führen. Die Elemente die zum Ende des Sprints nicht fertig geworden sind fallen weg und um genau das so gut es geht zu vermeiden, versucht das Team die passenden Features auszuwählen, die zum Ende des Sprints abgeschlossen werden können. Hier gilt die Faustregel: Auslieferbar geht vor Funktionsumfang. Dieses Prinzip wird auch Timeboxing genannt. Um das zu ermöglichen wird vor dem Sprint festgelegt ob die einzelnen Features realisiert werden können und welchen Aufwand dies erfordern würde. Ist der Aufwand zu hoch wird das Feature entweder aussortiert, gestückelt oder auf die Grundelemente runter geschraubt. Die Aufwandschätzung ist hier ein kleines Hindernis bei dem es zwei Punkte es besser zu überwinden als bei den Klassischen Methoden. 1. Der Sprint beinhaltet nur wenige Teile womit eine Schätzung etwas präziser wird und offenen Fragen zur Aufgabe wurden bereits durch die vorherigen Sprints vorbereitet. 2. Das Team verwendet bei der Schätzung eine Methode aus XP die sich "Planning Poker" nennt. Den Erfahrungen gemäß lagen die Schätzung immer erstaunlich gut. Timeboxing findet nicht nur im Sprint Anwendung sondern auch in anderen bereichen von Scrum in denen es darum geht etwas abzuschließen. Transparenz Was bei Kanban das WIP-Board ist, ist bei Scrum die Transparenz. Die Transparenz ist das mit Abstand wichtigste Argument für die veerwendung von Scrum. Im Grunde genommen wird lediglich das Sprint Backlog auf einem Whitboard festgehalten. In den Zeilen des Whiteboards stehen die jeweiligen Anforderungen und anhand der Spalten kann man den Fortschritt erkennen, da hier die Tasks Tickets im Daily Scrum nach rechts oder links wandern. Da das Whiteboard offen für jeden ist weiß auch jeder was aktuell passiert was zur folge hat, dass Fehler durch falsche Kommunikation und aneinander vorbei arbeiten verringert werden können. Fehler werden so immer direkt gesehen und zum Ausdruck gebracht und außerdem bringen die ganzen kleinen Fortschritte mehr Erfolgserlebnisse für das komplette Scrum Team. Rollen in Scrum Projekten Anders als bei den klassischen Vorgehensmodellen hat die Rollen Verteilung und der Stellenwert eine andere Bedeutung in Scrum Projekten. Es gibt im Grunde genommen nur drei verschiedene Rollen in Scrum: Scrum Master Der Scrum Master ist im Scrum Projekt das was der Projektmanager für die klassischen Vorgehensmodelle ist. Er ist für die Verfolgung und Umsetzung der Praktiken verantwortlich, die im Projekt benötigt werden. Für den Fall das Probleme oder Hindernisse (impediments) auftreten muss er die Lösung finden. Wichtig zu beachten ist, dass der Scrum Master mehr die Funktion eines Trainers oder Coachs hat und nicht die eines Leiters. Er organisiert Workshops etc. zur Lösungsfindung oder neue Ressourcen wie zum Beispiel bessere Werkzeuge. Der Scrum Master sollte auf keinen Fall Probleme ungelöst zurück zum Team schicken, da dies einen Rückfall im Projekt bedeuten würde. Product Owner Der Product Owner ist das Gegenstück zum Scrum Master. Er ist für das Projekt der Vertreter der Kunden und fällt Entscheidungen über neue Features oder die Umsetzung von alten. Der Product Owner verantwortet die Produkteigenschaften, aber auch er ist nicht der Leiter des Projekts und ist auch nicht verantwortlich für den Scrum Prozess. Entwicklungsteam Das Entwicklungsteam ist für das entwickeln und testen der Software zuständig und trägt auch die komplette Verantwortung für die Arbeitsschritte. Es organisiert sich selbst und trifft auch die Entscheidungen. Es soll so so geplant werden, dass jeder im Team gleichermaßen zum Fortschritt beiträgt und funktionsübergreifend arbeitet. So kann der Team Geist gestärkt werden da nun alle verschiedenen Spezialisten ein und das selbe Ziel haben und nicht in Rollen unterteilt werden . Das Ziel ist es ein cross-functional Team (interdisziplinär) zu bilden, bei dem zwar nicht jeder alle Aufgaben Bereiche direkt zu Anfang erledigen kann aber bei dem jeder bereit ist bei jeder Aufgabe mitzuwirken. Es geht hier immer um das Team als Ganzes und seinen Fähigkeiten und nicht um die einzel Aufgaben. Komponententeams Komponententeams werden meist bei größeren Projekten verwendet, bei Komponententeams wird das zu erstellende Projekt in mehrere Komponenten unterteilt und zeitgleich von mehreren Scrum-Teams bearbeitet. Dies ermöglicht es große Projekte in möglichst kurzer Zeit zu entwickeln. Category:Scrum Category:Agile Category:Software Category:Testing Category:Certified tester Category:Software Testing